搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2012-05-08, 18:23 下午 Jonas 注册: 2012-05-08 发 贴: 1 Strange call stack after using !analyze -v 老师您好：   我最近碰到一个问题， dump是用procdump这个工具抓的，运行命令!analyze -v显示如下：   FAULTING_IP: ntdll!KiRaiseUserExceptionDispatcher+3a 00000000`7764f6b7 8b8424c0000000  mov     eax,dword ptr [rsp+0C0h] EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 000000007764f6b7 (ntdll!KiRaiseUserExceptionDispatcher+0x000000000000003a)    ExceptionCode: c0000008 (Invalid handle)   ExceptionFlags: 00000000 NumberParameters: 0 Thread tried to close a handle that was invalid or illegal to close DEFAULT_BUCKET_ID:  STATUS_INVALID_HANDLE PROCESS_NAME:  store.exe ERROR_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified. EXCEPTION_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified. NTGLOBALFLAG:  0 APPLICATION_VERIFIER_FLAGS:  0 STACK_ADDR_RAW_STACK_SYMBOL: b535afa20 ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff] LAST_CONTROL_TRANSFER:  from 000007fefd6b1853 to 000000007764f6b7 FAULTING_THREAD:  ffffffffffffffff PRIMARY_PROBLEM_CLASS:  STATUS_INVALID_HANDLE BUGCHECK_STR:  APPLICATION_FAULT_STATUS_INVALID_HANDLE STACK_TEXT:  000007fe`fd6b9aef KERNELBASE+0x9aef 000007fe`fd6e39d2 KERNELBASE+0x339d2 000007fe`fd6e38fc KERNELBASE+0x338fc 000007fe`fd6b1aab KERNELBASE+0x1aab 00000000`7752c193 kernel32+0x4c193 0000000b`52427812 utilDebug!apr_file_unlock+0x42 00000000`7750309a kernel32+0x2309a 0000000b`524198f0 utilDebug!apr_file_write+0x200 0000000b`523df60c utilDebug!log4cxx::helpers::FileOutputStream::write+0x9c 0000000b`523839d3 utilDebug!log4cxx::helpers::Transcoder::encodeUTF8+0x13 0000000b`523900be utilDebug!log4cxx::helpers::UTF8CharsetEncoder::encode+0x2e 0000000b`52390511 utilDebug!log4cxx::helpers::CharsetEncoder::encode+0x21 0000000b`5237676c utilDebug!log4cxx::rolling::CountingOutputStream::write+0x2c 0000000b`5238e9d1 utilDebug!log4cxx::helpers::OutputStreamWriter::write+0x141 00000001`3ef96e97 msvcr80!malloc+0x67 00000000`77718288 ntdll!RtlpInterceptorRoutines+0x0 00000000`77651468 ntdll!RtlAllocateHeap+0xe4 00000001`3f01698f msvcr80!memcpy_s+0x6f 0000000b`5253bfbb msvcp80!std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >+0x2b 0000000b`52536467 msvcp80!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::append+0x127 0000000b`524499f0 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::Logger>::`vftable'+0x0 0000000b`5244b208 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::spi::Filter>::`vftable'+0x0 0000000b`5241ac05 utilDebug!apr_thread_mutex_unlock+0x15 0000000b`52534189 msvcp80!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::~basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >+0x19 0000000b`5235fe82 utilDebug!log4cxx::WriterAppender::subAppend+0xb2 0000000b`5235e971 utilDebug!log4cxx::WriterAppender::append+0x31 00000000`7764c9b0 ntdll!RtlLeaveCriticalSection+0x7b 0000000b`5238541f utilDebug!log4cxx::helpers::synchronized::~synchronized+0xf 00000000`77502a8a kernel32+0x22a8a 00000001`3ef96dfb msvcr80!free+0x1b 0000000b`5244c790 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent>::`vftable'+0x0 0000000b`52369aa4 utilDebug!log4cxx::helpers::MessageBuffer::~MessageBuffer+0x34 0000000b`523822d2 utilDebug!log4cxx::helpers::ObjectImpl::releaseRef+0x12 00000000`698f373c hookVsapi+0x2373c 0000000b`52350847 utilDebug!Log4cxxAdapter::WriteLog+0x237 0000000b`5244ab20 utilDebug!log4cxx::helpers::ObjectPtrBase::`vftable'+0x0 0000000b`5244859a utilDebug!`string'+0x0 00000000`698f3738 hookVsapi+0x23738 0000000b`5233f76b utilDebug!DBG::DebugLogEx+0x10b 00000000`77522ee8 kernel32+0x42ee8 00000000`77541554 kernel32+0x61554 00000000`77579337 kernel32+0x99337 00000001`3ef93ed9 msvcr80!_getptd_noexit+0x79 00000000`776377ba ntdll!RtlDecodePointer+0x2a 00000000`777290c4 ntdll!`string'+0xbf44 00000000`77696258 ntdll! ?? ::FNODOBFM::`string'+0x22c5 00000000`77634dc1 ntdll!RtlLookupFunctionTable+0xbd 00000001`3efcabe7 msvcr80!__CxxFrameHandler+0x77 00000000`77668115 ntdll! ?? ::FNODOBFM::`string'+0xd52d 00000000`7760b3a3 ntdll! ?? ::FNODOBFM::`string'+0x13548 00000000`77614ebc ntdll!_C_specific_handler+0x0 00000000`777290b8 ntdll!`string'+0xbf38 00000000`698d8540 hookVsapi+0x8540 000007fe`fd6b1865 KERNELBASE+0x1865 00000000`77748334 ntdll!CsrPortMemoryRemoteDelta <PERF> +0x0 000007fe`fd6b0000 KERNELBASE+0x0 000007fe`fd7130c0 KERNELBASE+0x630c0 00000000`775eedb4 kernel32+0x10edb4 00000000`698d0000 hookVsapi+0x0 00000000`69901894 hookVsapi+0x31894 00000001`3f04f348 msvcr80!_bufin <PERF> +0x0 00000001`3ef90000 msvcr80!_initp_heap_handler <PERF> +0x0 00000001`3f04f360 msvcr80!_bufin <PERF> +0x0 00000000`774e0000 kernel32+0x0 00000000`775ee940 kernel32+0x10e940 00000000`77600000 ntdll!RtlActivateActivationContext <PERF> +0x0 00000000`77745940 ntdll!CsrPortMemoryRemoteDelta <PERF> +0x0 00000000`7769db00 ntdll! ?? ::FNODOBFM::`string'+0x140f9 00000000`7764f65d ntdll!KiUserExceptionDispatcher+0x53 00000000`7764f6b7 ntdll!KiRaiseUserExceptionDispatcher+0x3a 000007fe`fd6b1853 KERNELBASE+0x1853 00000000`77502a51 kernel32+0x22a51 00000000`698f3670 hookVsapi+0x23670 00000000`698f3578 hookVsapi+0x23578 00000000`698d87fe hookVsapi+0x87fe 00000000`698f34e0 hookVsapi+0x234e0 00000001`3ef93f69 msvcr80!_getptd+0x79 00000001`3ef937d7 msvcr80!_callthreadstartex+0x17 00000001`3ef93894 msvcr80!_threadstartex+0x84 00000001`3f0495c0 msvcr80!__initialmbcinfo+0x0 00000000`774ff33d kernel32+0x1f33d 00000000`77632ca1 ntdll!RtlUserThreadStart+0x1d 00000000`77579280 kernel32+0x99280 FOLLOWUP_IP: KERNELBASE+9aef 000007fe`fd6b9aef ??              ??? SYMBOL_STACK_INDEX:  0 SYMBOL_NAME:  KERNELBASE+9aef FOLLOWUP_NAME:  MachineOwner MODULE_NAME: KERNELBASE IMAGE_NAME:  KERNELBASE.dll DEBUG_FLR_IMAGE_TIMESTAMP:  4e211da1 STACK_COMMAND:  ddS b535b0000 b53596000 ; dds b53596d08 ; kb 为什么线程的ID是ffffffffffffffff， 而且我用~*kb命令打印所有线程的call stack， 却没有上面提到的call stack, 请问这是为什么？ 一般发现“Thread tried to close a handle that was invalid or illegal to close” 这种error应该怎么解决？ IP 地址: 已记录   报告

2012-05-17, 13:42 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: Strange call stack after using !analyze -v 著名的无效句柄问题；很是巧合，这一期（6月）《程序员》杂志的专栏就是这个内容“谁关了我的句柄”。 如果问题可以重现，那么先使用App Verifier开启句柄监视功能，再重现问题，非常有效。 如果问题难以重现，只能继续分析这个dump，那么先解决符号问题，kernelbase模块的符号不对... IP 地址: 已记录   报告

高端调试 » 软件调试 » WinDbg » Strange call stack after using !analyze -v

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试